\section{Evaluation}
The aim of our evaluation was to measure the performance of our program against various user-supplied queries. We also looked briefly at ways in which our underlying APIs can be extended for use in current or new non-semantic web services. By preserving our custom star ontology with various data instances, we were able to validate the results of our in-house application against a predetermined range of queries along with their expected results.

\subsection {Test Configuration}
The tests were conducted using the following environment:
\begin{itemize}
\item IBM Thinkpad T60
\item 2.0 GHz Intel Duo Core T25000
\item 2.5 GB RAM @ 2.0GHz
\item Windows XP, Service Pack 3
\item Java JDK 6 Update 5
\end{itemize}

\subsection {Application Assessment}

\textbf{Searching by Location}
By the modular nature of our codebase, we were able to use the APIs for given purposes to create a Java web applet. This applet provided an indirect interface with these APIs to allow users to search for the star data that they needed. Some of the properties that were accessible in these searches were as follows:
\begin{itemize}
\item Latitudinal and Longitudinal coordinates
\item Right ascension and Declination coordinates
\item Time in day, month, year, hour, minutes, and seconds
\end{itemize}
Filling in the desired field of the application and submitting the query took between one and five seconds to load. The results appropriately showed a list of stars that were in proximity to the coordinate locations that were supplied.

Although we achieved the desired results in this case, the instability of the query time an artifact may be of concern with larger data, and can not be applicable for real-world use. However, we have demonstrated that the API can be extended to other applications.


\textbf{Searching by Name}
In this study case, we were able to obtain a result for the query ``Sun'', however, after submitting, the response time was subpar, taking almost twenty seconds to retrieve and post the results. The can be attributed to the manner in which the API handles searching based on an unindexed query string. We also found that the results retrieved for, for example, ``Sun'' returned duplicates with entries similar properties, varied only by missing fields in their rows.

Since we are still working on prototype versions of our API, we may consider revising the improving the search aspects by creating better query plans and result-filtering.

\textbf{Searching by NGC Number}
While testing this part of our application, using the NGC number ``2841'', the results were not returned in a time sufficient for any evaluation; we therefore consider this feature of the API to be broken.

\subsection {Extensibility Assessment}
We have shown that our API was able to successfully integrate with an application. Now, we are interested in how it can extend other applications in an explicit way by annotation and retrieval of input from an already existing traditional astronomy web service. As such, we chose Google Sky as both our benchmark for comparing the success rate of our queries results and also as for potentially improving our application annotation capabilities.

The evaluation for this portion will be two-parts: one on the assessment of application's ability to successfully annotate Google Sky, and the other for our application's ability of to successfully retrieve records against Google Sky's database.

\begin{figure}[h]
\caption{Embedding auxiliary web service with In-house App}
\label{fig2}
\centering
\includegraphics[scale=0.6]{images/Evaluation1.png}
\end{figure}

\textbf{Google Sky Extension}
In an attempt to improve to the semantics of Google Sky, we had to enhance our application code to embed it in with the original application interface. Specifically, the entire web page of the Google Sky interface was directly accessible from the control frame of our in-house application where the user can lookup the coordinates of a star from Google using its searching and interactive capabilities, independent of the application. Although this proved to be possible, we were unsuccessful in being able to interface with the web page more directly. This came at the cost of the language protocol in which our code was utilizing for embedding.

Due to the issue previously raised, we were not able to successful interactive with Google in order to have any means of mining, or query it's database against ours. This proved to be the downfall in our evaluation to properly assess our extensibility to external web services can be possible. Future considerations for properly interfacing with the language protocol of the embedding mechanism will have to be taken before carrying-out this evaluation.

\textbf{Annotating Google Sky}
As before, our attempts at interacting with the Google service were futile, and as a result, hinder our hopes at doing any proper benchmark testing against an establish online astronomy application that is within our domain.

\subsection {Final evaluation}
Although we were not successful in extending our in-house application with an existing web service for proper benchmark testing, we however, managed to find promising results from interfacing our API with a custom application. That is, our APIs were able to be used in a manner that can allow other applications to retrieve data from a semantic application.

Considerations that may have to be taken in the future, therefore, as follows:
\begin{itemize}
\item Way to successful extend Google Sky and other web services.
\item Improving query response
\item Possible to offload data to multiple stores, improving access
\item Porting APIs to languages
\end{itemize}